Hi. First of all, thanks for your work on those bindings, it is much appreciated!

Assigning a value to a conditionally chained field actually hits you with a SyntaxError: Left side of assignment is not a reference, which means the JS we're benchmarking against looks more like this:

const h2 = document.querySelector("h2");
if (h2) {
  h2.style.color = "red";
}

Still very succinct for sure, but a fairer comparison.

The current version of @rescript/webapi provides an asHtmlElement utility in the Webapi__Dom__Element module which returns an option (See here). I think your approach with tryParse from the HTMLHeadingElement side makes more sense. Not sure about the name (fromInstance?).

In any case, I'm not sure this function would fit in this library. I like the idea of having zero-cost bindings available and maybe a utility library on the side. The question then becomes: should @rescript/webapi be the zero-cost bindings library, with something like @rescript/webapi-utils for utilities and a more idomatic API, of instead be the accessible default while @rescript/webapi-raw provides the zero-cost version for those who want it?

If we suppose the utility library also wraps all nullables with options, we could dream of something like:

open WrappedWebAPI

Global.document
->Document.querySelector("h2")
->Option.flatMap(HTMLElement.tryParse)
->Option.forEach(h2 => {
  h2.style.color = "red"
})

which is still quite verbose but doesn't feel too bad to me.

Hello, thank you for your recent PRs and sharing your thoughts on this.
I think it make sense to keep @rescript/webapi a zero-cost bindings only package.
Something like @rescript/webapi-utils might fit the bill better. (Although, I don't like that exact name).

It also makes wonder if we should not go for a workspace approach with multiple packages.
Extract some parts of the current package into new packages to keep @rescript/webapi a bit more lightweight.